你的 App 專案正在緊鑼密鼓地進行中。今天下午，設計師給了你更新版的 UI 設計稿，其中一個關鍵的按鈕顏色，從藍色改成了綠色。

你心想：「好的，這個很重要，必須讓所有人都知道。」於是，你打開了那個有 50 個成員的專案 Slack 大群，把新的設計稿截圖貼上去，並標註了 @channel，寫道：「嗨，各位，最新的 UI 設計稿更新囉！重點是註冊按鈕的顏色，從藍色改成綠色了，請大家注意一下！」

你看著訊息成功發送，心中一塊大石落地，覺得自己盡到了告知的義務。

兩週後，測試版 App 熱騰騰地出爐。你打開一看，差點把手上的咖啡打翻，因為那個註冊按鈕，依然是刺眼的藍色。

你怒氣沖沖地跑去找負責的前端工程師，質問他：「我不是在 Slack 上說了嗎？按鈕要改成綠色！」

工程師一臉無辜地滑著手機，花了好幾分鐘，才從上千則訊息中，找到你那則被埋在各種插科打諢、系統通知和午餐訂單之下的「重要公告」。他聳了聳肩，說：「喔，這裡啊…我真的沒看到耶。那個頻道太多訊息了，我早就靜音了。」

你看著他，再看看那個藍色的按鈕，感覺自己的所有溝通努力，都被吸進了一個名為「已讀不回」的資訊黑洞裡。

症狀診斷

遇到這樣的狀況，我想你可以確診為「單向溝通妄想症」。

病根在於，我們天真地以為，「資訊已發送」就等於「溝通已完成」。

我們誤把專案的溝通，當成了一場「電台廣播」。我們以為只要按下發送鍵，所有聽眾都會自動打開收音機，專心收聽，並牢記在心。

但真相是，在資訊爆炸的現代職場，你的團隊成員每個人都活在自己的「資訊同溫層」裡。工程師專注於 Jira 和程式碼（沒有意外的話程式碼優先， 會自主乖乖檢查、更新 Jira 或是其他開票系統的工程師是稀有珍寶） ，設計師優先活在 Figma 裡，而你的老闆，可能只看 Email 和 PPT（或是 Line ☺️）。

你用單一頻道發出的廣播，對他們來說，很可能只是被靜音的背景噪音。

你不能像個 DJ 一樣，只把訊息「播」出去；更需要像一位米其林餐廳的「行政主廚」，精心設計每一道菜（資訊），並確保它以最合適的方式（溝通管道），在最精準的時間（溝通頻率），送到最需要它的客人（利害關係人）面前。

你的工作，不是當一個 DJ 或是公頻廣播電台，而是設計一份合適的「資訊餵食計畫」。

處方籤

這份處方提供的步驟，可以幫助你打造屬於你的「資訊餵食計畫」

第一步：成為「資訊行為」的偵探

在制定計畫前，先花一週的時間，默默觀察你的利害關係人們，是如何處理資訊的。

• 觀察清單：
  • 老闆： 他是習慣看 Email 裡的附件，還是在 Slack 上只讀粗體字的摘要？
  • 工程師： 他們是活在 Jira Ticket 裡，還是習慣在專屬的技術頻道討論？
  • 設計師： 他們是不是只看 Figma 裡的留言？
  • 業務團隊： 他們是不是只在每週的業務會議上，才有心思聽你說話？

第二步：繪製你的「溝通矩陣」草圖

根據你的偵查結果，為自己畫一張溝通矩陣的草圖，以下是一個範例表格：

第三步：擁抱「有耐心的重複」

這是治癒此病症最核心的心法。重要的資訊，絕對不能只說一次。 一個專業的 PM，會像一個厲害的廣告投手，用不同的素材（口頭、文字、圖表），在不同的渠道（會議、Email、Slack），對同一個目標受眾，進行多次的「資訊投遞」。

你的目標，不是避免重複，而是有策略地重複，直到你確信資訊已經被 100% 接收並理解。

臨床實戰：用「資訊餵食計畫」拯救那個藍色按鈕

好，讓我們回到開頭那個讓你胃痛的「藍色按鈕」場景。如果當時你手上已經有了這份「資訊餵食計畫」，情況會如何發展？

當你從設計師那裡拿到新的綠色按鈕設計稿時，你不會再衝動地發送 @channel。你會先深呼吸，然後打開你的「溝通矩陣」，像個專業的快遞員一樣，開始配送你的資訊包裹：

1. 第一站：Jira → 給工程師
   • 你會打開原本負責「註冊按鈕」的 Jira Ticket，將狀態改為「待辦」，並在留言區 @前端工程師，附上新的設計稿連結，並清晰地寫下：「規格變更： 註冊按鈕顏色，根據最新設計稿，從 #0000FF 修改為 #00FF00。」
   • 效果： 這個變更，被記錄在工程師每天都會看的工作系統中，成為一個可追蹤、有紀錄的正式任務。
2. 第二站：Figma → 給設計師
   • 你會在 Figma 的設計稿上，直接在那個綠色按鈕旁邊留言，並 @UI設計師：「嗨，這個新的顏色很棒，我已經更新到 Jira Ticket 上給工程師了。」
   • 效果： 確保設計師也知道，他的最新設計已經被採納並進入開發流程。
3. 第三站：每日站會 → 短暫、有效的全面性口頭提醒
   • 在第二天的每日站會上，你會口頭向所有人同步：「各位，提醒一下，註冊按鈕的顏色有變更，細節都已經更新在對應的 Jira Ticket 上了。」
   • 效果： 雙重保險，確保資訊在團隊內部有被聽到。

B 計畫：對方就是「金魚腦」或「已讀不回慣犯」時

好，我們來談談那個最無奈的「但是」。

如果，你已經有了完美的溝通計畫，但團隊裡就是有那麼一位健忘的同事，或是一位永遠不看 Jira 開票系統的主管，導致資訊依然卡住，該怎麼辦？（OS：這種人就應該一樣先鞭數十驅之別院）

那麼建議你的策略如下：

1. 從「非同步」溝通，升級為「同步」溝通
   • 不要再傳送更多的訊息，直接走到他的座位旁，或發起一個 5 分鐘的視訊通話。
   • 你可以這樣說： 「嗨，阿傑，不好意思打擾一下。關於那張 Jira Ticket #123，裡面有一個規格需要你確認，我們現在可以花兩分鐘快速看一下嗎？」
   • 如果他跟你說：「不行，我正在忙！」，那你就需要跟他押他可以討論的時間，絕對不要放過他！
2. 將「個人責任」，轉化為「公開承諾」：
   • 在每日站會或週會上，當著所有人的面，進行確認。
   • 你可以這樣說： 「好的，關於註冊按鈕的顏色變更，前端的阿傑這邊已經確認收到。那我們就期待在下週的測試版看到囉！」這句話的重點不是說給阿傑聽的，而是說給所有人聽的。
3. 如果一切無效，讓「流程」來當壞人：
   • 將這個溝通問題，變成一個流程改善的議題，在複盤會議中提出。
   • 你可以這樣說： 「各位，我觀察到我們最近常常發生『Jira 上的規格更新，但沒有被即時看到』的狀況，這導致了一些重工。我想和大家討論一下，有沒有什麼更好的方法，可以確保這類重要資訊不會被遺漏？」

在過程中引導團隊，共同建立一個更可靠的溝通機制，來彌補人性的弱點。

最後的醫囑

所以，下次當你準備發送一則重要的專案訊息時，請先停下來問自己一個問題：

「我的目標，是『把話說出去』，還是『讓事做對』？」

一個專業的 PM，從不假設自己的訊息會被自動接收，一定會像一個超偏執的快遞員，精心規劃路線、選擇最合適的交通工具，並在包裹送達後，堅持要對方親自簽收。

因為在專案管理的世界裡，沒有被確認的溝通，就等於沒有溝通。

每當遇到已讀不回的慣犯：

你給我吃！